1. Field of the Invention
The present invention relates to memory management during page processing and more particularly to optimizing memory management of Web storage attributes during page processing.
2. Description of the Related Art
Page processing refers to the receipt, interpretation and rendering of a markup language defined page in a content browser. The most well-known form of a page processing content browser at present is the venerable Web browser in which Web pages are received, processed and rendered. In a conventional Web browser, a markup language page—typically a page defined according to the hypertext markup language (HTML) markup language specification—can be received, interpreted and rendered in a display of a computer. Integral to the HTML processing capabilities of the Web browser is the cookie feature.
The cookie feature provides for short term data storage of state information for a Web page. Cookies have been used for many reasons including session management, personalization and tracking. However, according to the hypertext transfer protocol (HTTP) specification on statement management, a Web browser in respect to the use of cookies need only support a minimal number of cookies. In particular, according to the HTTP specification, a Web browser is expected only to be able to store three-hundred cookies of four kilobytes each, and only twenty cookies per server or domain.
While the cookie feature of HTML can provide a tempting mechanism for data storage in page processing, for many applications—and in particular in light of advances in the acquisition and transfer of digital information such as digital imagery and audio, a client side mechanism of greater capacity is desirable. The HTML version 5 specification addresses this need in defining “Web Storage.” Web Storage picks up where cookies left off. In this regard, Web Storage provides both a simple application programming interface (API) to getter and setter methods for attributes specified in terms of key/value pairs, and also a default disk space quota of no less than five megabytes per fully qualified domain name.
Importantly, Web storage falls exclusively under the purview of client-side scripting. In other words, the scoping of Web storage attributes is under the discretion of a developer. Therefore, it is left to the developer to decide the lifetime of an attribute as well as the scope or location of where different attributes are stored, such as locally, for a HTTP session, or on a server. A Web storage attribute placed in local storage is per domain—the Web storage attribute is available to all scripts from the domain that originally stored the Web storage attribute. Therefore, a Web storage attribute placed in local storage, persists even after the Web browser closes. In contrast, session storage is per-page-per-window and is therefore temporally limited to the lifetime of the window. Of course, server side storage of an attribute persists for as long as the attribute remains in the server side storage and is made accessible to requesting pages.
Because scoping of the Web storage attributes are at the discretion of the developer, developers oftentimes misuse the scoping and storage of Web storage attributes, which can further reduce the scalability of a Web application. For example, when a developer stores an object that contains a vast amount of information, correct data placement storage problems can arise. For instance, if state or country lists occur in a form, but a developer stores the entire form into local memory, the memory on a computing device is not utilized most efficiently. Instead, information (state or country data) that is global or will not change based on a user should be stored on a server (or on a database on the server or on a database coupled to the server) and should be queried when needed rather than placed in local storage.